home *** CD-ROM | disk | FTP | other *** search
- Newsgroups: comp.lang.modula3,comp.lang.c++,comp.lang.java
- Path: news.u.washington.edu!uw-beaver!news
- From: Brian Bershad <bershad>
- Subject: Re: Java closer to Modula-3 than to C++
- Content-Type: text/plain; charset=us-ascii
- Sender: news@beaver.cs.washington.edu (USENET News System)
- Content-Transfer-Encoding: 7bit
- Organization: Computer Science & Engineering, U of Washington, Seattle
- Message-ID: <DnoB9p.MAI@beaver.cs.washington.edu>
- X-Url: news:1996Mar1.143408.951@friend.kastle.com
- References: <31308FE2.167E@sophia.inria.fr> <1996Feb26.192508.2614@friend.kastle.com> <DAGENAIS.96Feb29113254@hagen.vlsi.polymtl.ca> <1996Mar1.143408.951@friend.kastle.com>
- X-Mailer: Mozilla 1.1N (X11; I; OSF1 V3.2 alpha)
- Mime-Version: 1.0
- X-Nntp-Posting-Host: twirl.cs.washington.edu
- Date: Sun, 3 Mar 1996 04:03:25 GMT
-
- rich@kastle.com (Richard Krehbiel) wrote:
- >dagenais@hagen.vlsi.polymtl.ca (Michel Dagenais) wrote:
- >
- >>In article <1996Feb26.192508.2614@friend.kastle.com> rich@kastle.com (Richard Krehbiel) writes:
- >
- >> Oh, I think it's clear that C++ gets it's success from C. C #includes
- >> and libraries can (almost always) be called upon in C++ programs.
- >> Nothing like that can be said of Modula-3 or Java.
- >
- >>Well, too bad i did not know i could not do it. I have called X libraries,
- >>unix system calls, the gnu dbm library, ODBC drivers... from Modula-3 without
- >>problem.
- >
- >Well, then you've managed the easy half of the battle. Now get
- >Modula-3 to include C header files and make proper sense of them.
- >
- >--
- >Richard Krehbiel, Kastle Systems, Arlington VA USA
- >rich@kastle.com (work) or richk@mnsinc.com (personal)
- >
-
- Actually, for a bunch of reasons, you don't want this functionality.
- Wilson already mentioned the problem of alignment disparity. Other problems
- you have when blindly going from M3 to C or the other way are:
- - traced refs. if C puts a traced ref into its untraced heap,
- you'll get into trouble. We've addressed this problem by
- adding a StrongRef interface that can be used to prevent the
- compiler from collecting OR moving a ref before it gets passed
- to C.
- - <*EXTERNAL*> functions, when declared in safe M3 interfaces
- are in no way guaranteed to be safe. By this, I mean that
- anyone can write a safe interface that for example, lets you call
- an integer over in C. Bad news. We've addressed this problem
- by disallowing the use of <*EXTERNAL*> in safe interfaces. If you
- call into C, then you need to know what you're doing is likely to
- be unsafe and you should advertise that to clients of the interface.
-
- We have to deal with this kind of stuff all the time in SPIN, since we
- rely on vendor device drivers for our kernel. The basic way we deal
- with this is by writing wrapper services for all the EXTERNAL c functions.
- It's almost always the case that the wrappers have to do something semantically
- interesting before calling out to C.
-
- None of this argues that you can't use C from M3; you just have to do
- it carefully. By analogy, M3 doesn't prevent you from designing unsafe
- implementations, you just have to be careful in how and when you use
- those implementations (think of all your C code as a kind of unsafe M3
- implementation and everything makes sense).
-
- Finally, C++ has no inherent advantage in integrating with C. If you use
- any of the advanced constructs in C++, you're going to get in trouble when
- you call into C unless you're careful.
-
- Brian
-
-